【レポート】オールコネクトDX挑戦とAmazon Connect 導入〜国産レガシーCTIからピュアなクラウド型CTIへ〜 #AWSSummit

AWS Summit Online Japan 2020

#レポート

#Amazon Connect

#AWS

春田拓海 | Takumi

2020.09.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

DA事業本部の春田です。

AWS Summit Online絶賛開催中！ということで、本記事では「CUS-96: オールコネクト DX挑戦 Amazon Connect導入国産レガシーCTIからピュアなクラウド型CTIへ」の内容についてまとめていきます。

セッション情報

株式会社 ALL CONNECT 情報システム本部本部長前田知也氏

昨年8月から弊社内コンタクトセンターへの導入を進めていた（現在も一部進行中）Amazon Connect導入プロジェクトについてユーザー企業の立場から事例紹介させていただきます。導入決定に至るまでの経緯、現時点で構築可能な機能、プロジェクト進行中の課題など、2020年現在の国内事例としては比較的大規模なものになるかと存じますため、AmazonConnectを導入検討されている企業様のご参考となれば幸いです。

※セッション動画は以下リンク

アジェンダ

会社紹介
なぜ10年も使っている国産CTIから移行しようと思ったか？
プロジェクトの体制
プロジェクトの課題
今後の取り組み
まとめ

会社紹介

株式会社オールコネクト
- 福井本社: 福井県福井市栂野町第15号1番地2
- 東京支社: 東京都港区浜松町1丁目3-1 浜離宮ザ・タワー4F
- 従業員数 : 連結従業員数814人（2020年5月時点）
- オウンドサービス事業（MVMO事業）
  - 固定通信サービスを自社ブランドとして取り扱い、販売・運営
    - WiMAXやLTEなどの移動体通信サービスや、光回線や光コラボレーションモデルなど
- ライフイノベーション事業
  - 通信事業者様の販売代理店として、Web広告の展開・サイト運営・コンタクトセンター運営を行い、集客〜販売までをワンストップで提供
業績推移
- 5期連続売上120%増を達成中!

ビジネスモデル
- 集客~販売までをワンストップでお客様に提供
- Web広告からWebサイトにつなげ、問い合わせをサポートするコンタクトセンターを運営
- MVMO事業のコンタクトセンターも自社運営

コンタクトセンター紹介
- 席数規模（委託先含む）
  - 800席程度
- 拠点（委託先含む）
  - 福井、東京（新宿・五反田・渋谷）、大阪、神戸、青森、山形、新潟、福岡、宮崎
- 主な業務
  - インバウンドの申し込み手続きサポート
  - サービス/料金説明
  - クライアント様取次後の不備解消
  - カスタマーサポート
- 月間平均コール数
  - 受電: 30万件
  - 架電: 30万件

なぜ10年も使っている国産CTIから移行しようと思ったか？

①保守期限切れ
- 来年1月に部品調達も出来なくなり、故障したら終わりの状況だった
- 2カ月前に（10年間で初めて）PBXサーバーが故障
- 大阪から代替機を福井iDCまで搬送し、事なきを得る
②増席/拠点追加/拠点停止に時間がかかる
- 業界/会社的にスピードが速く、コンタクトセンターの増席/拠点追加を即時実施したい
- 既存CTIを新拠点に展開する場合、ネットワーク接続等の工事含め2-3カ月は最低でも必要だった
③耐障害性/耐災害性
- 複雑に絡み合った音声系ネットワークをシンプル化したかった
- Amazon Connectを導入すればシンプル
  - AWSへのネットワークにさえ繋がっていれば良い
  - 複数拠点に障害が発生する致命的な状態を回避できる

④レポート機能を上手く使えていない
- ダッシュボード・レポート機能が弱く、全チーム共通で閲覧できるものが無かった
- 各チームそれぞれで、受架電に関するCSVデータを出力
  - 他システムのデータと紐づけ・加工しながら独自の集計を行っていた
  - 無駄が多かったり、集計の定義間違えが多かった

⑤変化に追従できない
- 既存CTIを稼働させ10年、様々な戦略・施策が実行された
  - CTIは変わることができず、周辺システムを増殖させる結果となった
- 今後も市場・業界の変化により、コンタクトセンターが取るべき行動も変わっていくが、今のままで追従できるのか?

→ 曖昧かつ不確実なビジネス状況の中であっても、コンタクトセンターに必要な機能を高い機動力で提供したい

プロジェクトの体制

プロジェクト体制におけるポイント
- Positive
  - 導入予算は社長決裁
  - AWS Japan、ウフル社（担当ベンダー）の手厚いサポートあり
  - 利用部門側の巻き込みに成功。部長級を担当としてプロジェクトに参加
- Negative
  - 利用部門側のコンタクトセンターが3本部あり、意見集約が困難
株式会社ウフルについて
- 2006年2月設立
- 従業員数259名
- 良かった点
  - 会社の文化・業務・課題を深く知ろうとしてくれる
  - カスタマーサクセスに基づき忌憚なく意見交換ができる
  - 非常に高度な技術力
    - ターボエンジンと呼ばれるエンジニアがスピーディに技術課題を解決してくれた

プロジェクトの進め方
- スモールスタートを徹底
  - 全拠点一気に変更はしない
  - 比較的規模が小さい拠点のコンタクトセンターからスタート
  - 並行して必要最低限に絞り機能開発を進める
  - Amazon Connectのアップデートも期待されるため作りすぎは避けたかった
- 運が良かったところ
  - 既存CTIの方はあまり多機能に使えていなかったこともあり、機能面で利用部門側の違和感は出にくかった

構成
- Amazon Connect × Salesforce
- 顧客からの電話・LINE・SNSをAmazon ConnectとSalesforceで受ける
- 他社製品との連携も容易
- 今後業界的にも流行るパターン？

プロジェクトの課題

課題: CTI選定フェーズ

コンタクト本部の中期計画との連動を重視
- 徹底的な省力化
  - オートコール
  - 音声テキスト化
  - IVRを迅速に変更
- 新たな働き方
  - 在宅コールセンター
→ 絶対に後で変わる要件！とは思っていた
クラウド型を中心に国産/海外問わず6製品から比較
- 有名な製品は早々に除外
  - コンタクト本部側の中期計画も今後変遷していくため、初期投資が大きすぎた
- クラウド型を謳っていても、実際は違ったり
  - プライアンス設置が必要
  - クライアントアプリのインストール、定期的なアップデートが必要
  - PSTN引き込みが必要
- 新しいテクノロジに追従出来るかが心配
  - 今後の新たなコンタクトセンタートレンドに追従できるほどのアップデートがあるか懸念
    - 初期投資の小さい安価な製品に絞っていったため
Amazon Connectの場合
- 今後も頻繁なアップデートが期待される
- 同時にCRMの刷新を行っており、Salesforceの採用を決めていた
  - → 連携機能に期待
- 初期費用なし、使った分だけ課金
- 完全なクラウド型、インターネットさえ繋がればどこでも使える
- 葛藤もあった
  - 本当に当社が先行して導入するべきなのか?
  - 国内には小規模事例しかないが、成功できるのか?
  - 今選ばなかったら恐らく5年~10年は機会が無い
  - → AWS Japan、ウフル社の手厚いサートで解消!
    - 製品の魅力に加えて、体制面でAmazon Connectを選択

課題: 導入フェーズ

課題1: 発信番号が選択できない
- マルチスキルで稼働しているオペレーターが多く、発信番号をオペレーター毎に1つしか持てない仕様はNG
→ 発信者番号の選択機能をカスタマイズ開発
- ①SF(Salesforce)内部のオブジェクトで、ログインユーザごとに発信可能な番号を管理
- ②カスタマイズしたCCP画面の発信番号選択値を保存
- ③アウトバウンドウィスパーの問合せフロー内部で、AWS Lambdaを経由してSF内の発信番号選択値を参照
- ④問合せフロー内部の発信時に③の番号を利用

課題2: 変化を受け入れる必要がある
- 既存CTIとはルーティングプロファイル・キューの概念が違う
  - → 業務の見直しも必要となるため理解を得る必要がある
- 大規模、複雑な問い合わせフローはメンテナンスが困難
  - → 可能な限り簡素にする
- 複雑になりがちな場合はあえて細分化した問い合わせフローを作成・繋げる
  - → メンテナンス性などを向上
- → 導入を機に、各チームで独自運用していた問合せフローの見直しを行い、共通化・標準化を推進
課題3: アップデートが早い
- 本番構築直前にver4.2へのアップデート
- → ウフル社に非常に頑張っていただいた。やはり作りすぎ注意。
課題4: 途中でコロナ対策が急務となり、在宅コールセンターを1週間で構築
- Amazon Connect × Amazon WorkSpacesを利用して在宅勤務型のコールセンターを1週間で構築
- 仮想デスクトップ環境から社内システムにセキュアにアクセスし、重要データもAWS上に保存
- セキュリティを確保しつつ、在宅コールセンターを短期間で実現

課題5: 番号数が非常に多く、管理画面でのメンテナンスが困難
- → Salesforceから複数項目を一括変更する管理画面を構築

課題: 導入後

導入後に電話料金が高騰したと利用部門からクレームあり
- 原因
  - お客様をお待たせしている「着信待機時間」に対して課金が発生する
    - 既存ツールの統合やFD基本料金面ではコスト優位性があるが、着信待機時間が一定量増えると既存と比べて割高になる
  - 先行してAmazon Connectに移管した、とあるチームの着信待機時間が異常に高くなっていた
    - 通話時間29時間に対して、着信待機時間377時間
- 対策
  - （為替相場も考慮に入れた）着信待機時間の上限値（閾値）を設定し、超えないように管理する必要がある
- 進化
  - 「お客様をお待たせしない」「無駄を徹底的に削減する」にマインドチェンジ
  - Amazon Connectの機動力を活かし、改善のPDCAを実行していく
- 事例
  - 着信待機時間比率32%を維持することでコスト維持可能（※AC社内の場合）

着信待機時間削減の具体的な取り組み
- 折り返し電話予約IVRの設置 → 完了
  - 急激な受電増加により取り切れない場合、IVRにて折り返し電話予約が可能なシステムを構築
  - KPIモニタリング・ダッシュボードの構築 → 対応中
  - Amazon Kinesis + Amazon S3 + Kibanaでダッシュボードを構築
  - 委託先、在宅も含め、全ての拠点および環境で着信待機時間をリアルタイムにモニタリング可能にする

今後の取り組み

音声テキスト化（Text to Speech）の活用
- S3に保管された音声データをAmazon Transcribeでテキスト化
- 活用方法を今後検討

オートコール機能を実装し、架電効率を向上させる
- ①Salesforce側でオートコールのスケジュール・設定を管理するオブジェクトを追加
- ②（予定）Cron的なものを用意し、スケジュール・設定オブジェクトを参照する
- ③Cron的なものからLambda → Amazon Connect発信API